This section is intended to introduce the reader to various aspects of the art that may be related to various aspects of the present invention. The following discussion is intended to provide information to facilitate a better understanding of the present invention. Accordingly, it should be understood that statements in the following discussion are to be read in this light, and not as admissions of prior art.
Policy and Charging Control PCC was defined in 3GPP Release 7. The PCC architecture includes the PCRF (Policy and Charging Rules Function) that provides service data flow detection and, policy and charging control towards a PCEF (Policy and Charging Enforcing Function). These functions are provided by means of the so called PCC rules. A PCC rule is a set of information enabling the detection of a service data flow and providing parameters for policy control and/or charging control. The PCRF receives service information from the H-AF (Home Application Function) as input to generate PCC rules that include the SDF (service data flow) filters and QoS requirements for the particular service requested by the AF. The PCC rules are then installed at PCEF that enforces them providing service data flow detection and policy enforcement. When the PCRF provides PCC Rules to the PCEF, the PCEF decides if the QoS requirements requested within the PCC Rule requires the establishment of a new bearer towards the RAN. Functionalities defined for PCRF and PCEF can be implemented in specialized nodes, or can be co-located with nodes performing further functions. For example, gateway nodes, such as GGSN or, more generally, gateway nodes interfacing media for user terminals, such as Packet Data Network Gateways nodes (PDN-GW), preferably implement the enforcing functions defined for a PCEF.
3GPP Rel-8 standardizes the “off-path model” that includes the BBERF (Bearer Binding and Event Reporting Function) within the PCC architecture for those cases where GTP protocol (GPRS Tunneling Protocol) is not used between the serving gateway S-GW and the PDN-GW. The BBERF provides service data flow detection, bearer binding and event report functions (it reports events to the PCRF). The BBERF allows exchanging PCC information between the access gateway A-GW (that includes a BBERF) and the PDN-GW (that includes a PCEF) using the PCRF as mediator. This PCC information is carried over GTP but cannot be transported over the mobility protocols (DSMIP, PMIP v6 and MIP v4) that have been included in the Rel-8 Evolved Packet Core Architecture.
The PCRF receives service information from the H-AF as input for to generate PCC rules. The PCRF provides PCC Rules to the PCEF and QoS Rules (subset of the PCC rules that do not include changing info) to the BBERF. The BBERF decides if the QoS requirements that the service identified by the SDF description within the QoS Rule requires the establishment of a new bearer towards the RAN.
The “off-path model” introduces the need to deploy a new reference point between the PCRF and the BBERF, named Gxx. In addition to that, the “off-path model” introduces the need to deploy a PCRF in the VPLMN and a new inter-operator reference point, named S9, to communicate PCC information between the V-PCRF and the H-PCRF.
In roaming scenarios it may happen that PCC is not deployed by either the VPLMN or the HPLMN. For those scenarios where the VPLMN does not deploy PCC (e.g. when roaming to a non-3GPP access not supporting PCC), it is not possible to provide the following PCC functions (as described in [3GPP TS 23.203 v. 8.3.1 Policy and Charging Control Architecture (Release 8)] clause Limited PCC support):                Dynamic QoS control in the VPLMN and        Event reporting from the VPLMN to the HPLMN.        
However, PCC can still be used for the purpose of charging in the HPLMN.
A mechanism based on local static configuration both at the H-PCRF and at the OCS has been defined in [3GPP TS 23.203 v.8.3.1 Policy and Charging Control Architecture (Release 8)]. The local configuration is based on roaming agreements. The H-PCRF is aware that the UE is roaming in a PLMN that does not support either dynamic QoS Control or Event Reporting. The OCS is aware that the UE is roaming in a PLMN that does not support Event Reporting. FIG. 1 shows limited PCC deployment in home routed scenarios. VPLMN does not support PCC.
In regard to problems with existing solutions, this invention relates to the following roaming scenario:
The UE is roaming (in a VPLMN)                Home-Routed scenario: traffic is sent to the HPLMN        PCC is deployed in the HPLMN but not in the VPLMN        A protocol with no QoS information support is used in the way from the UE to the PCEF (off-path model using PMIP, MIP v4 or DSMIPv6).        
FIG. 2 shows the problem description and target scenario.
The static mechanism that is defined to allow the HPLMN to detect whether dynamic PCC is supported by the VPLMN is based on roaming agreements (i.e. PLMN-id where the UE is currently roaming) presents the following problems:                The identifier of the PLMN where the UE is roaming is not sent to the HPLMN. The PLMN-id (MCC+MNC) where the UE is roaming is not available at the PCEF. The PLMN-id is sent to the PCEF when GTP is used but it is not sent over any of the mobility protocols (PMIP, MIP v4 or DSMIPv6). The static configuration cannot for the moment be based on VPLMN identifiers. The static configuration needs then to be based on other information such as PCEF obtaining the IP address of the A-GW; then, there must be a mapping table from IP address ranges to PLMN-id.        The configuration of the mapping table must be coordinated between the PCRF's and OCS instances in the HPLMN. This means that a centralized OAM system is required to perform the task to configure the H-PCRF's and the OCS with the correct information.        In a deployment scenario where within the same PLMN, some A-GW support S9 and some A-GWs do not supported yet, the mapping tables become much more complex. The mapping tables may have to include the full IP addresses of the A-GWs.        
Additionally, there is a fundamental problem for the H-AF not covered by the static configuration mechanism defined in [3GPP TS 23.203 v.8.3.1 Policy and Charging Control Architecture (Release 8)]. Since H-AF cannot know whether the QoS Authorization provided to the H-PCRF and associated to H-AF service sessions can be enforced through the network or not. The H-AF will act as if the QoS Authorization can be successfully enforced. However, the related QoS policies cannot be traversed through the VPLMN and therefore the VPLMN cannot reserve the corresponding resources. Consequently the service delivery may suffer some degradation or it may even not be possible to be completed creating a faulty situation for both the operator and the user.
A more detailed description of the limited deployment of PCC functions in the system is now provided. If Gxx/S9 interface is not supported the following PCC functions are not available:                QoS control: It is not possible to authorize resources for a certain service session according to the service requirements.        Event Reporting: It is not possible to report any events detected at the VPLMN to the H-PCRF. As a consequence, the H-PCRF cannot subscribe to these events, make policy decisions based on that information nor to report them either to the PCEF or to the H-AF.        
The lack of these PCC functions has the following consequences:
1. The H-AF will contact the H-PCRF to request Dynamic Policy and Charging Control, but only Charging Control is available.                The H-AF will not be notified about it, the service delivery will not be under operator control but it will depend on the UE capabilities to set up new bearers.        
2. The H-PCRF will not be able to authorize in a proper way the session information received over Rx interface.                Since the H-PCRF does not know about the authorized GBR, therefore subscription based admission control will not be performed.        
3. Wrong Charging might be applied to the service.                The OCS will not be notified about any IP-CAN session modification due to a credit reauthorization or an event trigger.        
4. Wrong policies might be applied to the service.                The H-PCRF will not be notified about any IP-CAN session modification due to a credit reauthorization or an event trigger.        
5. Unknown bearer-initiated capabilities and BCM at the H-PCRF.                The H-PCRF cannot know whether the network initiated procedures are supported by all the nodes in the network since this parameter is not transmitted via DSMIP or PMIP protocols.        H-PCRF cannot assign the BCM to be used for this IP-CAN session. It is not defined how the A-GW or the UE will react when the BCM is not set by the H-PCRF.        
6. Incorrect attempts for dedicated bearer establishments by the network.
The H-PCRF and optionally the PCEF (chained case) are not aware of the network deployment. This results in incorrect enforcements and inappropriate policy decisions.